Week Overview
Mon – Fri · 10 hours total
Split-horizon DNS and a production-style web server — then reading the logs to find out what broke
Week 4 has two halves that share a common thread: both DNS views and Nginx server blocks are about serving different responses to different clients from the same machine. A split-horizon DNS server gives internal clients internal IPs and external clients public IPs — the same domain name resolves differently depending on who asks. An Nginx server with virtual hosts serves different websites on the same port depending on the Host header. Both concepts are fundamental to how real infrastructure works.
Days 1–2 extend the Week 3 DNS server with BIND9 views. The existing yourname.net zone is restructured into internal and external versions with separate zone files. Days 3–4 build a production-style Nginx installation: virtual host serving the yourname.net domain, SSL/TLS with a self-signed certificate, Diffie-Hellman parameters, and an HTTP-to-HTTPS redirect. Friday's troubleshooting module is new content not in the original labs — students diagnose deliberately broken Nginx configurations using only the access and error logs.
Week at a glance
Monday
DNS Views — Setup
Split-horizon concept, ACL definitions, backup existing zone, restructure into internal and external views (Lab 4A)
Tuesday
DNS Views — Verification
Test split responses from internal and external clients, per-view zone files, view ordering, recursion settings (Lab 4B)
Wednesday
Nginx — Virtual Host & SSL
Install Nginx, create virtual host, symlink to sites-enabled, generate self-signed cert, DH params, ssl-params.conf snippet (Lab 4C)
Thursday
Nginx — HTTPS redirect & log-based troubleshooting
301 redirect, access.log format, error.log, diagnosing 403/404/502/SSL errors, nginx -t workflow (Lab 4D)
Friday
Mini-Assessment 4
Written: DNS views, Nginx config, SSL concepts. Practical: diagnose a broken Nginx config using logs.
Learning Outcomes
By end of Week 4, students can…
Explain split-horizon DNSDescribe why internal and external clients need different DNS responses for the same hostname, and how BIND9 views implement this
Configure BIND9 viewsDefine named ACLs, write internal and external view blocks with separate zone declarations, and migrate existing zones into the view structure
Verify split DNS responsesUse dig from both internal and external clients to confirm different answers are returned based on source IP
Install and configure NginxCreate a virtual host server block, link it into sites-enabled, create the document root, and verify with curl and a browser
Implement SSL/TLS on NginxGenerate a self-signed certificate and DH parameters, configure the self-signed.conf and ssl-params.conf snippets, and add a 301 HTTP-to-HTTPS redirect
Read Nginx logs diagnosticallyInterpret access.log fields (status code, response size, user agent), read error.log context messages, and diagnose 403, 404, 502, and SSL handshake failures from log output alone
Use nginx -t for config validationRun nginx -t before every restart, interpret its output, and use it to locate syntax errors in server block files
Monday
Lecture + Lab 4A · 2 hrs
Split-horizon DNS — why it exists, how BIND9 views work, and migrating existing zones
0:00–0:30
Lecture
0:30–1:50
Lab 4A
1:50–2:00
Debrief
- Lecture (30 min): The split-horizon problem — a company's web server has a public IP (172.17.x.x) and an internal IP (192.168.50.1). If all clients use the same DNS record, internal clients route traffic out the gateway and back in, wasting bandwidth and breaking some services. Views solve this by matching the client's source IP to the appropriate zone file. Key BIND9 view concepts: match-clients (which sources this view applies to), view ordering (first match wins — most specific first), recursion per view (yes internally, no externally), ACL definitions. Critical migration issue: once views are used, every zone must be inside a view — zones outside all views cause errors.
- Lab 4A (80 min): Back up existing zone files and named.conf.local. Define ACLs for internal and external networks in named.conf.options. Restructure named.conf.local with internal-view and external-view blocks, each containing its own declaration of yourname.net. Create separate internal and external zone database files with appropriate IPs in each. Validate with named-checkconf. Restart BIND9 and verify in the journal that both zones loaded.
- Debrief (10 min): Key question: "What happens if you put the external view before the internal view?" — internal clients match the external view (because it uses match-clients { any; }) and never see the internal zone. View order is critical. Preview Tuesday: testing that split responses actually work.
Migration warning: Moving an existing zone into a view is one of the most error-prone operations in this course. Zones that previously existed outside any view must now be inside a view — BIND9 returns an error if a zone declaration exists both inside and outside a view block. All existing zones (including the reverse zone from Week 3) must be migrated into both views or BIND9 will refuse to start.
Tuesday
Lab 4B · 2 hrs
Test split-horizon responses, per-view zone content, secondary DNS with views, recursion behaviour
0:00–0:10
Recap
0:10–1:50
Lab 4B
1:50–2:00
Debrief
- Recap (10 min): Verify BIND9 started cleanly — check the journal for both zone load lines. Ask: "What does recursion no on the external view actually do? Why is that important?"
- Lab 4B (100 min): Test responses from S2 (internal view): dig @S1 yourname.net from S2 should return the internal IP. Test from the Windows host (external view): dig @S1-ExternalIP yourname.net from the Windows machine should return the external IP. Update zone files to reflect realistic internal vs external records. Explore secondary DNS with views — the secondary server must also use view blocks and its zone declarations must match the primary. Verify the allow-transfer directive still works correctly inside views. Test recursion: internal clients should resolve google.com via S1; Windows host should get REFUSED or SERVFAIL for recursive queries.
- Debrief (10 min): Discuss: "What is the security benefit of recursion no on the external view?" — prevents S1 from becoming an open recursive resolver that can be used in DNS amplification attacks. Preview Wednesday: Nginx.
Wednesday
Lecture + Lab 4C · 2 hrs
Nginx architecture, virtual hosts, self-signed SSL/TLS, DH parameters, snippet approach
0:00–0:10
Recap
0:10–0:40
Lecture
0:40–1:50
Lab 4C
1:50–2:00
Debrief
- Recap (10 min): Quick DNS verify — can the Windows host browse to www.yourname.net (after pointing its DNS at S1's external IP)? If not, that's the diagnostic challenge for Wednesday's warm-up. Preview the Nginx server block concept and how it mirrors what the DNS views just taught.
- Lecture (30 min): Nginx as a web server vs. reverse proxy. The event-driven architecture that makes it efficient at high concurrency. sites-available / sites-enabled pattern — staging vs. active configuration. Server block anatomy: listen, root, index, server_name, location. How Nginx decides which server block handles a request (Host header matching). SSL/TLS fundamentals: the certificate chain, what a self-signed cert means, why browsers warn, what the DH parameter file does. The snippet pattern for SSL configuration — centralising cipher settings so they apply to all virtual hosts without duplication.
- Lab 4C (70 min): Install Nginx. Create document root and index.html. Write virtual host server block in sites-available, symlink to sites-enabled. Test with curl and nginx -t. Generate self-signed certificate. Generate DH parameters (warn: this takes 2–5 minutes). Create self-signed.conf and ssl-params.conf snippets. Add HTTPS server block with snippet includes. Test with browser — accept the cert warning.
DH parameter generation timing: The openssl dhparam -out /etc/nginx/dhparam.pem 4096 command takes 2–5 minutes. Start it early in the lab and work on other steps while it runs. Students who wait for it to complete before moving on will run short on time. This is good practice for understanding that security operations have real computational cost.
Thursday
Lab 4D · 2 hrs
HTTP→HTTPS redirect, per-site log files, and log-driven troubleshooting of Nginx failures
0:00–0:10
Recap
0:10–1:50
Lab 4D
1:50–1:55
Bonus
1:55–2:00
Wrap
- Recap (10 min): Ask: "A visitor browses to http://yourname.net (port 80). Right now what happens?" — they see the site over HTTP, unencrypted. Today we fix that with a 301 redirect to HTTPS, and add per-site log files so we can isolate this site's traffic from other Nginx activity. Then we break things deliberately and diagnose them from the logs.
- Lab 4D (100 min): Add the 301 redirect server block (listen 80, return 301 https://). Add per-site access_log and error_log directives. Watch logs live with tail -f while generating requests. Then the troubleshooting module: introduce four deliberate faults one at a time — wrong document root (403/404), removed symlink (connection refused), bad certificate path (SSL error), and a server_name mismatch. For each fault: read the log entry, identify the error, fix it, verify recovery.
- Bonus (5 min): Configure Nginx as a basic reverse proxy — add a location block with proxy_pass pointing to a simple Python HTTP server running on localhost. This previews the Week 6 Docker capstone.
- Wrap (5 min): The log troubleshooting methodology introduced today applies to every service with logs. From here forward, the expected first response to any broken service is: check the log. Preview Friday assessment and Week 5.
⭐ Thursday Bonus — Nginx reverse proxy preview
- Start a simple Python HTTP server:
python3 -m http.server 8080 &
- Add a location block to the Nginx HTTPS server block:
location /proxy/ { proxy_pass http://127.0.0.1:8080/; }
- Reload Nginx and browse to
https://yourname.net/proxy/
- Nginx forwards the request to the Python server — the browser sees it as a seamless part of your site. This is exactly what Week 6's Docker capstone does at a larger scale.
Friday
Mini-Assessment 4 · 2 hrs
Written (30%) + Practical: diagnose and repair a broken Nginx config using logs (70%)
0:00–0:30
Written
0:30–1:45
Practical
1:45–2:00
Review + Preview W6
- Written (30 min): DNS views — match-clients, view ordering, recursion no purpose. Nginx server block directives, sites-available/enabled pattern, nginx -t usage. SSL certificate generation commands, what DH parameters do, HTTP 301 redirect syntax.
- Practical (75 min): Students receive access to S1 with a broken Nginx configuration. The site is not loading. Using only nginx -t, access.log, error.log, and man pages — diagnose all faults, repair the configuration, and demonstrate a working HTTPS connection to the instructor.
- Review + Week 5 Preview (15 min): Walk through log entries for common errors. Preview Week 5: VPN — IPSec with StrongSwan using PSK, then certificates, then WireGuard. The PKI concepts introduced in the SSL week carry directly into the certificate-based VPN configuration.
Mini-Assessment 4 — Topic Coverage
| Topic | Weight | Source |
|---|
| DNS views — purpose, match-clients, view order, recursion | 15% | Monday lecture + Labs 4A/4B |
| Nginx server block directives — listen, root, index, server_name, location | 15% | Wednesday lecture + Lab 4C |
| sites-available/enabled pattern and nginx -t workflow | 10% | Lab 4C |
| SSL/TLS — cert generation, DH params, snippet approach, 301 redirect | 20% | Labs 4C/4D |
| Log-driven troubleshooting — reading access.log and error.log | 10% | Lab 4D |
| Practical: diagnose and repair Nginx from logs | 30% | All week |
What you need ready before Monday
Week 3 DNS zones working cleanly (yourname.net forward + reverse)
Lab 4A, 4B, 4C, 4D handouts printed
Windows host DNS pointing at S1 external IP for browser testing
Mini-Assessment 4 printed (Friday)
Broken Nginx scenario prepared for practical assessment